


'J: / 


fm 

iimCTEP S@WH 


, (NASA-CR-138753) OPERATIONAL CONCEPTS FOE N74-28324 

SELECTED SOfiTIE MISSIONS: EXECUTIVE 

(SUMMARY Technical Report, Aug. 1973 - 

Jun. 1974- (TEH Systems) 00 Unclas 

CSCL 22B G3/31 41922 




J y l"r ?i i . . ,v. 

.v*v. ‘ 




• i fit 


Jf .'y ■ 

■ 

W t YV’ 
■V£ r ' =■ 


^OHMT.CHHICAL 


■•ritluUgsj 


^7d, VA- 22.51^ 


P(7© r^O 7©Co] (/©!/. 


AglS®NA'.OT<S§ A'Xl® §S>A(gg A®MOfe98§?r$A?0®M 

■v. . mm Po (sswra 

(SHNiniB, 



<> a»; <9w?f»g# &&& momm mm 



24981 F006-RO-00 


EXECUTIVE SUMMARY 


OPERATIONAL CONCEPTS 
FOR 

SELECTED SORTIE MISSIONS 


Contract NAS10-8395 


JUNE 1974 


Prepared for 

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION 
JOHN F. KENNEDY SPACE CENTER 
KENNEDY SPACE CENTER, FLORIDA 



V. A. Dulock, Jr. 
Study Manager 
TRW Systems Group 







NASA Technical Manager 
Kennedy Space Center 


I 


FOREWORD 


* 


The Operational Concepts for Selected Sortie Missions study was con- 
ducted by TRW Systems Group for the John F. Kennedy Space Center, Kennedy 
Space Center, Florida, The study was conducted from August 1973 to June 
1974 under Contract NAS10-8395. 

This document presents an executive summary of the study work and is 
submitted in accordance with the requirements stated in Section 7.4 of the 
contract statement of work. The complete study documentation consists of 
the following individual reports: 

Study Plan , 24981-FOOl-RO-OO , August 1973 

Detailed Technical Report - Volume I, 24981-F002-R0-00 , 

November 1973 

Detailed Technical Report - Volume II, 24981-F003-R0-00 , 

February 1974 

Detailed Technical Report - Volume III, 24981-F004-RO-00 , 

June 1974 

Narrative Report, 24981-F005-R0-00 , June 1974 

Executive Summary, 24981-F006-RO-00 , June 1974 

The TRW study team operated under the technical direction of a KSC 
Study Technical Management Team chaired by Mr. R. L. Norman. The member- 
ship of the Technical Management Team is: 

LL-PMO/R. L. Norman, Chairman 
LS-ENG/E. C. Johnson 
IN-PLN-l/D. C. Clark 
SP-PAY/D. Bailey 
LV-GDC-4/B . Haynes 
S0-LAB-3/C . W. Hoppesch 
AD-MS0-1/K. Steel 
JSC, ER-4/E. Crum 
MSFC , PD-SL/C. Casey 

In addition to the Technical Management Team, the TRW study team 
received agency-wide guidance and overview by a NASA Steering Committee 
to assure optimum technical and program continuity and to maximize objec- 
tivity in concept development. The membership of the NASA Steering Committee 
is : 
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Hdqtrs., MTX/W, 0. Armstrong, Chairman 
KSC , SP-PAY/H. E. McCoy 
Hdqtrs. , MFI/B. G. Noblitt 
Hdqtrs. , MHO/ John L. Hammersmith 
Hdqtrs., SG/Dr. Gerald W. Sharp 
Hdqtrs., ES/Clarence E. Catoe 
Hdqtrs., RS/William C. Hayes, Jr. 

MSFC, PD-SL-MGR/Thomas J. Lee 
MSFC, PD-SL/ William A. Huff 
JSC, TA-2 /Richard F. Hergert 
LaRC, 418/ W. Ray Hook 
ARC, SSO/Donald R. Mulholland 
JPL , 180-403/Wilbur A. Collier 
GSFC, 110.0/William G. Stroud 
Hdqtrs., MMS/James F. Whitmer, Col. 

Questions concerning this study may be directed to: 

R. L. Norman 

Attention: LL-PMO 

John F. Kennedy Space Center 

Kennedy Space Center, Florida 32899 

Telephone (305) 853-5566 

V. A. Dulock, Jr. 

TRW Systems Group 
7001 N. Atlantic Avenue 
Cape Canaveral, Florida 32920 
Telephone (305) 783-0870 
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1 . 0 BACKGROUND INFORMATION 


This project is the second of two studies which have investigated the 
"Quick-Reaction 11 approach to space experiment integration for the Shuttle 
era. The idea behind Quick- React ion (QR) is that certain experiments are 
relatively simple to integrate with an appropriate experiment carrier; there- 
fore, a payload carrying only this class of experiments could be integrated 
in a very short time period with a minimum of formalized procedures. It is 
felt that the resulting time and cost savings would significantly expand the 
Shuttle user market. 

In the first study (NAS10-8043) , the very successful Ames Airborne Science 
Program (CV-990 Program) was selected as a model. The Ames Program is charac- 
terized by quick response, extensive user participation, simplified procedures, 
operational flexibility, informality, and low cost. The objective, as shown 
in Figure 1, was to determine if these characteristics could be retained in 
the more severe operational environment of manned spaceflight. 


CV-990 PROGRAM 
CHARACTERISTICS 


MANNED SPACE 
PLIGHT CHARACTERISTICS 

• LOW OPERATIONS 


• HIGH OPERATIONS 

COST PER MISSION 


COST PER MISSION 

• KNOWN < MODERATE 


• LITTLE KNOWN, SEVERE 

ENVIRONMENT 


ENVIRONMENT 

• LOW RISK VEHICLE 


» HIGH RISK VEHICLE 

OPERATIONS 


OPERATIONS 



EXTENSIVE 

DOCUMENTATION 


Figure 1. The Quick-Reaction Concept 


To develop this idea, 24 representative simple- to- integrate experiments 
covering a variety of scientific disciplines were used. The Sortie Lab, then 
being defined by the Marshall Space Flight Center, was selected as the experi- 
ment carrier. A goal of 90 days turn-around from arrival of experiment hard- 
ware at the launch site to return of data to the user (Principal Investigator) 
was established. The overall cycle, from experiment concept to data return. 
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would be about one year. The payload integration activities would occur at 
the Shuttle launch site, and they would have to be compatible with Orbiter 
turn-around schedules. 

Using these inputs, a Quick-Reaction integration concept was developed 
which preserves the principal advantages of the CV-990 Program and also meets 
the minimum safety and compatibility requirements of the Shuttle Program. The 
concept defines functional approaches to hardware integration, software inte- 
gration, and mission integration. To support these integration activities, 
minimum essential programmatic functions, including configuration management, 
safety, reliability, quality control, and documentation were defined. This 
model then provided the basis for estimating manpower requirements, facilities 
requirements, organizational relationships, and launch site integration costs. 

The principal features of this initial Quick-Reaction integration con- 
cept are: 

• Experiments are limited to those which are simple to integrate; 
that is, relatively autonomous, no complex calibrations or align- 
ments, and easy to operate. (With the trend toward increased 
hardware modularity, a growing number of experiments can be ex- 
pected to fall in this category by the 1980s.) 

• Five to ten experiments are flown per mission. Available integra- 
tion time is the limitation. 

• Experiment integration is performed by a small artisan team of 
highly skilled, versatile personnel working closely with the ex- 
perimenter on the one hand, and the Sortie Lab maintenance crew on 
the other. 

• Maximum use is made of existing facilities, shops, manpower, and 
other services available at the launch site. 

• Software integration is simplified by use of a remote LPS terminal 
at the experimenter’s home lab prior to his delivering the hard- 
ware to the launch site. 

• Mission planning is simplified by complying with mandatory formal 
procedures where necessary, but allowing informal procedures where 
possible. 

• A simplified documentation system, based on a User’s Guide, reduces 
formal paperwork, 

• A QR Mission Manager provides a single-point contact for the users. 

The first study thus resulted in a feasible concept which satisfied the 
QR objectives. A follow-on study was then defined with these objectives: 

• Investigate in more detail certain specific topics such as soft- 
ware integration, mission planning, and configuration management. 
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• Develop the QR concept to reflect the modular Spacelab configura- 
tion which had replaced the unitized Sortie Lab configuration base- 
lined for the first study. 

• Determine the impact of a second shuttle launch site on the QR 
concept . 

• Develop an operational concept for QR space-available payloads 

The remainder of this Executive Summary deals principally with the follow- 
on study. 


2.0 SUMMARY OF STUDY CONCLUSIONS 


General conclusions : 

• The short "concept-to-data-return" cycle and the user convenience 
of the Quick-Reaction concept are extremely desirable features 
and should be made available. 

• The simplified ground operations and management concepts defined 
in this study indicate that a QR Spacelab mode is feasible. 
Furthermore, these concepts may have application to other planned 
missions . 

• The baseline concept developed in this study provides a user- 
oriented, low-integration-cost service; however, the relatively 
high flight costs per experiment on a dedicated QR mission may 
discourage low-budget users. 

• The rr space— available" approach is feasible and is more suitable 
for low— budget users because flight costs are shared with the pri- 
mary user. 

• The commercial QR user, in either the dedicated or space-available 
mode, may encounter a launch support cost reimbursement environ- 
ment similar to that currently faced by Special Interest Launch 
users today. 

Spacelab as a Quick-Reaction carrier : 

• The split-module features of Spacelab result in more flexibility 
in the integration activities and allow selection of experiments 
from a larger market. 

Software integration : 

» To meet QR objectives, processing and display of experiment data 
by the Spacelab Data Management System must be limited to that 
required for normal control of equipment. 

Mission planning : 

• Quick-Reaction missions require an automated mission planning 
system (assumed to be operational in the Shuttle era). 
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• Iteration of final mission plans can occur as late as ope month 
prior to launch. 

Configuration management : 

• Simplified configuration management is feasible for the Spacelab 
Experiment Unit and Pallets if rigid control is maintained only 
where safety and interface compatibility are involved. 

• The Support Unit and other operational flight hardware should be 
controlled in the same manner as the Shuttle itself. 

Documentation : 

• The experimenters 1 involvement in documentation can be made very 
simple and informal by means of a Quick- Reaction User T s Guide. 

• Exchange of documentation between the QR activity and other support 
activities will be essentially the same as for other Shuttle users. 

Integration alternatives : 

• Performing the QR integration at any of several alternative loca- 
tions has minimal impact on cost and schedule. 

• Performance and management objectives are best met by accomplish- 
ing all integration at a single location. 

Space Available concept : 

• The current traffic model indicates that there are enough missions 
with space available for a QR experiment carrier to confirm this 
concept as a viable alternative mode of operation. 

• The opportunity for sharing flight costs with the primary user 
makes this mode attractive to low budget users. 


3.0 QUICK-REACTION OPERATIONAL CONCEPT UPDATE 


The principal areas in which the baseline operational concepts were 
developed are as follows: 


• Technical planning 

— Functional requirements 

— Functional flows 

Facility, GSE, and 

manpower requirements 

• Technical concepts 

— Hardware integration 

— Software integration 

— Mission integration 
— Equipment pool 


• Management system concepts 

— Requirements management 
— Configuration management 
— Documentation 
— Work Breakdown structure 
— Organization 
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3.1 SPACELAB AS A QUICK- REACT ION CARRIER 

The Spacelab configuration used for this study is shown in Figure 2. The 
Support Unit (SU) houses the Spacelab operational subsystems. The subsystems 
for the Experiment Unit (EU) and Pallets are essentially extensions of the SU 
subsystems. For example, the thermal control subsystem operates in the SU, 
but the EU/Pallet contain piping and cold plates to serve the experiments. 
Experiment hardware is located in the EU or on the Pallets, as appropriate. 

The SU, the EU, and Pallet section are each about 10 feet long. 

Assumptions and guidelines used for analysis purposes include. 


• Two Quick-Reaction flights per year. 

• The launch center is the owner /operator of the Quick-Reaction EU/ 
Pallet. 

• The launch center maintains the SU. 

• The Spacelab maintenance and checkout station, the experimenter s 
laboratories, and the EU/Pallet work stations are located in the 
Operations and Checkout (O&C) building at KSC. 




PALLET 


SU SUBSYSTEMS 

EU SUBSYSTEMS 

PALLET SUBSYSTEMS 

• ECLS 

§ 

• STRUCTURE 

• POWER DIST, 8. CTL 

• STRUCTURE 

• POWER DIST. & CTL 

• DATA MANAGEMENT 

t DATA LINES 

• THERMAL CONTROL LOOPS 

f THERMAL CONTROL 

« THERMAL CONTROL LOOPS 

• DATA LINES 

• CONTROL & DISPLAY 
t FLUIDS/ 6ASES 

• STRUCTURE 

• COMMUNICATIONS 

1 STABILIZATION 

• fluids/gases 

• EXP. CONTROL S DISPLAY 

• STABILIZATION 

• fluids/gases 


Figure 2. Spacelab Configuration Used for This Study 

The principal feature of the split module Spacelab is that it allows the 
experiment integration activities to be decoupled from the processing of opera 
tional flight hardware. Figure 3, a top-level, time-based functional flow 
diagram of the ground operations, shows off-loading of the QR Spacelab from 
the Orbiter immediately after post-landing operations. The SU and EU are 
demated, and the SU is processed for flight with another (non-QR) EU. The 
Quick-Reaction EU/Pallet are processed separately for the next QR flight. As 
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the diagram shows, the EU/Pallet processing does not become critical until 
the final 17 days, during which the EU/Pallet are integrated with an SU and 
the Orbiter. 


LAUNCH 



Figure 3. Quick-Reaction Spacelab Ground Operations Timeline 


Detailed development of the functional flow identified all specific func- 
tions necessary to support the QR integration operations. These were organized 
into the work breakdown structure shown in Figure 4. 

QUICK - REACTION PAYLOAD 
CHECKOUT & INTEGRATION OPERATIONS 


QRI 

PLANNING 
& CONTROL 

INTEGRATION 

ENGINEERING 

EXPERIMENT UNIT 
MAINTENANCE & 
MODIFICATION 

PLANNING 

ANALYS 1 S 

SUBSYSTEM 

MAINTENANCE 

SCHEDULING 

DESIGN 

SUBSYSTEM 

CONFIGURATION 

SAFETY £ 

TEST £ C/0 

CONTROL 

COMPATIBILITY 
SPEC REVIEW 

MODIFICATION 

DOCUMENT 



CONTROL 

TEST 

REQUIREMENTS 


ADMINISTRATION 

ENGINEERING 


LOGISTICS 

LIAISON 


MISSION 



MANAGEMENT 




EXPERIMENT 

EXPERIMENT 

QR 

INTEGRATION 

SOFTWARE 

MISSION 

& TEST 

INTEGRATION 

INTEGRATION 

INTERFACE 

SPACELAB 

FLIGHT 

HARDWARE 

DMS SIMULATION 

ASSIGNMENT 

FABRICATION 

DEVELOPMENT S 

ANALYSIS 

HARDWARE 

MAINTENANCE 

SUPPORT 

INSTALLATION 

PI SOFTWARE 

EXPERIMENT 


DEVELOPMENT 

FLIGHT 

INTEGRATION 

LIAISON 

OPERATIONS 

& TEST 

SHUTTLE FLIGHT 

REQUIREMENTS 

DATA ANALYSIS 

SOFTWARE 

EXPERIMENT 

& EVALUATION 

LIAISON 

FLIGHT 

OPERATIONS 

POST-FLIGHT 

EXPERIMENT- 

PROCEDURES 

EXPERIMENT 

SPACELAB 


HARDWARE 

FLIGHT SOFTWARE 

FLIGHT 

REMOVAL 

TEST 

VERIFICATION 

OPERATOR 

FAMILIARIZATION 

PROCEDURES 


MISSION PLANNING 
LIASON 


Figure 4. QRI Concept - Work Breakdown Structure 
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Analysis of the work breakdown structure shows a natural division between 
operational activities and R&D activities. Without experiments on board, the 
EU/Pallet have hardware and operational requirements similar to the SU. There- 
fore, EU/Pallet maintenance and modifications should be an extension of the 
SU maintenance and modification activity. Experiment operations are R&D in 
nature and should be performed by a dedicated Quick-Reaction Integration Activ- 
ity (QRIA) . 

The recommended QRIA organization is shown in Figure 5. The two dotted- 
line groups at the left are planned elements of the Shuttle operations at 
the launch site and perform the operational activities. The remaining groups 
perform the R&D activities associated with the experiment integration. The 
mission managers serve as a single-point contact for the experimenters to 
simplify their working interfaces. A total of 62 personnel can accomplish 
the integration activities, assuming two flights per year. This group is 
composed of highly skilled, versatile engineers and technicians so that the 
need for formalized procedures and paperwork can be minimized. 



Figure 5. QRIA Organization 
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The integration activity can be accomplished within the existing O&C 
building. About 16,500 square feet of floor space is required, including the 
EU/Pallet work area, experimenter’s labs, an environmental qualification lab, 
and storage area. Cost of facilities modification (in 1973 dollars) is estimated 
at $700,000. An additional $1,300,000 is required for ground support equipment, 
bringing the total implementation cost to $2,000,000 (not including EU/Pallet 
costs) . 


3 . 2 SOFTWARE INTEGRATION 

Many Quick-Reaction experimenters may wish to utilize the Spacelab Data 
Management System (DMS) to provide command, control, monitor, recording, and 
downlink functions. To accomplish this, the necessary experiment software 
must be compatible with the DMS, thus requiring a software integration pro- 
cess. The study objectives were to identify software integration criteria 
for both the experimenter and the overall software integration process, and 
then to update the software integration concepts developed in the initial 
study. 

The Spacelab DMs\ shown in Figure 6, provides the following from the 
user’s point of view: 

© Standard digital interface to the DMS computer via Digital Inter- 
face Units (DIU) 

• A dedicated hardwire interface to the Data Exchange Control Unit 
(DECU) for high data flow requirements 

• Analog interfaces via dedicated cables with standard impedance and 
voltage 

• Analog and digital tape recording capability 

• Command, control, and monitoring via three, multiforraat cathode 
ray tube displays 

• Two-way interface with the Orbiter for selected monitoring and com- 
munication with the ground and other external systems 


'It should be noted that recent Spacelab DMS concepts include separate com- 
puters for experiment control/monitoring. The advent of a dedicated experi- 
ment computer is not thought to materially affect the Quick-Reaction software 
integration criteria presented in this report. 
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SPACE LAB 


ORBITER 



NARROWBAND DIGITAL 
DATA - SUBSYSTEMS 


AUDIO 


WIDEBAND DIGITAL 
DATA'EXPERIMENTS 

ORBITER TRANSMITTER 

VIDEO 


Figure 6. Spacelab Data Management System 


The principal experiment /DMS interfaces are shown in Figure 7. As shown, 
the primary software interface is with the DMS computer. The extent of this 

interface and the resulting 



software integration job and 
its complexity will be deter- 
mined by the degree of experi- 
ment control and experiment 
data control required by the 
particular QR experiment. 

To keep the software integra- 
tion within the QR concept, 
the following interface 
criteria were defined: 


Figure 7, Experiment /DMS Interfaces 
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Experiment /DMS Computer Interface 


• Degree of control shall be limited to that achieved through the 
real-time acquisition of discrete events data and digital data; 
the processing of that data; and the issuance of discrete, func- 
tional commands, 

• Displays shall be limited to presentation (alphanumeric /graphical) 
of current operation experiment data for control/monitoring pur- 
poses . 

• DMS computer shall not provide a scientific/engineering analysis 
capability, 

• Degree of experiment checkout, fault detection, and isolation shall 
be limited to normal control of equipment configuration; the initi- 
ation of built-in self-tests; and the acquisition and display of 
resulting data. 

Experiment /DECU Interface 


• Experiment digital data shall be encoded and formatted to be compati- 
ble with the Orbiter transmitter, 

• Experiment analog signals shall be conditioned to be compatible with 
Orbiter avionics - the DECU shall provide for communication and sub- 
carrier oscillators compatible with Orbiter transmitter circuitry. 

To accomplish the software integration, it was assumed that a DMS soft- 
ware group will exist as part of the SU/EU operational activity (i,e., not 
part of the QR activity). This group will maintain the DMS software; perform 
all operational software process activities related to design, coding, test- 
ing, and integration; demonstrate that experiment software meets user require- 
ments; and perform prelaunch compatibility demonstration. 

The experimenter provides experiment control requirements based on the 
DMS utilization criteria. He then monitors the software development for his 
experiment, certifies that it satisfies acceptance test criteria, monitors 
the integration process, and participates in the prelaunch checkout process 
to provide continued assurance of experiment and experiment control readiness 
in the Shuttle environment. 


This software integration concept stresses user participation and simplic- 
ity while at the same time providing adequate assurance of compatibility and, 
possibly with some modification, appears to be applicable to other Spacelab 
missions . 
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3.3 MISSION INTEGRATION 


Mission integration is the process by which the experiment operational 
requirements are translated into a detailed mission plan which assures that 
experiment objectives will be met. Experiment operational requirements in- 
clude such items as: position, attitude, timing, stability, pointing, targets, 

RE coverage, and telemetry. The mission plan includes such elements as: 
launch time, trajectories, experiment schedules, attitude profiles, ground 
track, target availability, operating procedures, and timelines. 

The Quick-Reaction user’s role in mission integration is shown in Fig- 
ure 8. Upon receiving an Announced Flight Opportunity (AFO) or perhaps ear- 
lier, the user submits his experiment proposal to a sponsor for funding. 

Using the guidelines defined in the Quick-Reaction User’s Guide, he submits 
his experiment requirements and flight requirements to an Experiment Selec- 
tion Committee. Upon committee approval, a flight assignment is made, and 
the user’s requirements are entered into a mission planning function. In 
the meantime, the user may be developing his hardware for shipment to the 
launch site. 



Figure 8, Mission Requirements Integration Flow 
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The mission planning function selects a specific set of experiments to 
fly on a given mission from a roster of available experiments. The selection 
criteria are principally concerned with compatibility of experiment require- 
ments; that is, the several experiments selected for a flight must have require- 
ments which are sufficiently similar so that all experiment objectives can be 
met . 

Because the mission planning function is very complex, a high degree of 
automation is required to meet the QR schedules. Submission of final experi- 
ment requirements to mission planning nominally should occur about six months 
prior to launch, but the process must allow for iteration of mission plans 
up to one month before launch. Several efforts are now underway within NASA 
to streamline the mission planning function for the Shuttle era. It is assumed 
that these will result in a process that will satisfy the QR requirements. 

3.4 CONFIGURATION MANAGEMENT 

The configuration management problem is one of defining a concept which 
satisfies the rigid control requirements for operational hardware, i.e. , the 
Support Unit (SU) , Experiment Unit (EU) , and pallets, and, at the same time, 
allowing flexibility and simplicity for the experiments. The system should 
allow configuration changes to be initiated internally by the Quick-Reaction 
activity and by the carrier development center. Both permanent and temporary 
changes must be processed. Finally, the concept must be compatible with over- 
all Shuttle configuration management planning. 

The approach used to develop the configuration management concept is 
shown in Figure 9, Principal inputs were the Shuttle Level II requirements, 
the Atlas-Centaur plan, and an airline plan. The latter two are examples of 
effective programs which are currently operational and provided the basis 
for developing a QR concept which is consistent with the Shuttle Level II 
requirements . 

For the SU, it is recommended that configuration be maintained in the same 
manner as for the Shuttle vehicle. The dominant reason is that this is an 
operational unit committed to various missions, including the QR mission. 

This approach avoids separate procedures and it satisfies KSC guidelines for 
launch center operational responsibility. 

For the EU/Pallet , configuration need not be maintained as rigidly except 
where safety and SU interfaces are involved. The EU will be operated and 
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Figure 9. Approach to Developing the Configuration Management Concept 


maintained exclusively by the QRIA, so that its configuration control can be 
vested within the QR organization. 

Since the EU/Pallet will usually carry a different complement of experi- 
ments on each mission , some reconfiguration will be required prior to each 
flight. Some of this reconfiguration may be permanent, and some temporary. 

For QR purposes, a temporary configuration change is defined as one which is 
effective for a single mission only. 

The permanent change flow is shown in Figure 10. Change requests may 
be initiated either by the QRIA or by the development center. The Configura- 
tion Committee which approves changes is composed of representatives from 
each element of the QR organization plus Safety. The dashed lines show that 
status information is provided to the Planning and Control function at nearly 
every step of the flow. This is a formal procedure with all permanent changes 
well documented with respect to justification, technical/design adequacy, 
fabrication/installation correctness, and handbook update requirements. 
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Figure 10. Experiment Unit Permanent Change Flow 


The temporary change flow is shown in Figure 11. Here the user may 
initiate a change request. The QR Mission Management approves changes, sub- 
ject to concurrence by Safety and to review by the Configuration Committee. 
Consistent with the QR philosophy, the QR Mission Manager also relieves the 
experimenter from the need to closely monitor detailed activities not directly 
concerned with the actual operation/performance of his hardware. This is 
largely an informal procedure in which documentation is minimized and formal 
control is maintained only where safety and Orbiter compatibility are of 
concern. 

Experiment hardware configuration is controlled only for safety and inter- 
face compatibility. The User’s Guide defines functional interfaces and safety 
requirements. If the user requires a change, he provides the necessary inter- 
face and safety data to the QR Mission Manager. The QR Mission Manager approves 
significant changes and initiates the change processing. 
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Figure 11. Experiment Unit Temporary Change Flow 
3 . 5 DOCUMENTATION 

The documentation concept defined in this study represents a major depar- 
ture from existing Space Program documentation systems. The principal differ- 
ences are in the use of the Quick-Reaction User's Guide and in the role of the 
QR Mission Manager. Every effort is made to make the system as simple as possi- 
ble from the user's point of view, and to retain as much informality as possible. 
At the same time, all essential functions of a conventional documentation system 
are retained. 

The QR requirements documentation flow is shown in Figure 12. The User's 
Guide, prepared by the QR activity, provides the user with all information 
he needs. It describes the Shuttle Program, the QR mode, Spacelab and its 
subsystems, policies, and procedures. It delineates facilities, interfaces, 
safety specifications, quality requirements, and schedules. It provides guid- 
ance for experiment design and integration requirements. Finally, it provides 
tear-out sheets and special forms which the experimenter may use to submit 
his requirements. 

The QR Mission Manager provides direct, informal support to the user to 
assist him in every way necessary. He also provides a single-point interface 
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Figure 12. Quick-Reaction Experiment Requirements Flow 

for the user with the QR activity and other support activities. This approach 
relieves the user of otherwise burdensome documentation requirements and mini- 
mizes his working interfaces. 

3 . 6 EQUIPMENT POOL 


An added service which the Quick-Reaction activity might provide to the 


user is an equipment pool. As shown 
of general - purpose mission 
equipment and support hardware 
that is available to the user 
on request. The rationale for 
the pool is that many users 
will have common requirements , 
and hence a significant cost 
saving will result. The 
objectives in this study were 
to define the pool concept and 


in Figure 13, this pool stocks a variety 



GSE 


Figure 13. Types of Pooled Hardware 
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to identify any problems and tradeoffs* 

The pool concept is shown in Figure 14. The User’s Guide lists avail- 
able equipment which can be requested by means of tear-out sheets. The equip- 
ment may be sent to the user’s home laboratory for his use in experiment 
development, or it may be used only at the launch site. An example of the 
latter might be a flight-certified gas bottle which is required for flight 
but not for use in the laboratory. Most experimenters will require such 
equipment as standard mounting racks and brackets. After flight, the equip- 
ment may be returned directly to the pool, or to the user’s home laboratory, 
if required for final calibration or data control. 


PI ACTIVITY 


QR ACTIVITY 



pi's home lab 
experiment development 


pi /sponsor 
procurement 


flight certified 

EQUIPMENT & 
COMPONENTS 


EXPERIMENT SETUP 

(partial) 



PROCUREMENT 



SPACELAB installation 
& PRE-LAUNCH CHECKOUT 



POST FLIGHT 
ACTIVITY 



Figure 14, Equipment Pool Procedures 

Further evaluation of the pool concept is recommended, principally to 
determine if the pool should be exclusive to the QR program or should service 
all payload programs. The more detailed evaluation also would establish equip- 
ment selection criteria, methodology for cataloging, scheduling and loan proce- 
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dures, and a maintenance approach. Other considerations are cost allocation, 
integrity maintenance of flight-certified hardware, priorities, and liabilities. 
These latter considerations become significant where high-cost equipment may 
be used for extended periods at the user's home laboratory. 

3.7 INTEGRATION ALTERNATIVES 

The baseline Quick-Reaction concept developed in this study assumes that 
the integration activities take place at the launch site. Other location options 
were considered and qualitatively evaluated. 

For this analysis, four levels of integration, shown in Figures 15 through 
18, were defined as follows; 

Level IV - Instrument Assembly Integration 

Assembly of individual instruments and their unique support subsystems 
into a compatible package of equipment to accomplish specific mission 
obj ectives . 

Level III - Instrument to Supporting System Integration 

Integration of one or more instrument assemblies with Spacelab elements: 

A. Instruments into racks or on pallets 

B. Racks into rack sets or pallets into pallet sets 

Level II - Spacelab Elements into Cargo Integration 

Assembly of Spacelab elements into a cargo for a single Shuttle flight: 

A. Rack set to experiment section 

B. Rack set to support section; experiment section to support sec- 
tion; pallet set to integrated pressurized section; Spacelab 

to general purpose mission equipment 

Level I - Cargo-Shuttle Integration 

Integration into the Orbiter of everything that goes on a single Shuttle 
flight: 

A. Total cargo to Orbiter simulator 

B. Total cargo to Orbiter 
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Figure 15. Level I Payload Integration 



Figure 16. Level II Payload Integration 
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Figure 17. Level III Payload Integration 



Figure 18. Level IV Payload Integration 
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In addition to the launch site, a development center and a central inte- 
gration site were considered as location alternatives. Noting that Levels IIB 
and I must be performed at the launch site, the five options shown in Figure 19 
were developed. The factors considered were: 


Performance 

• User oriented approach 

• Use of existing skills and 
experience 

Costs 

• Facilities /equipment 

• Manpower 

• Transportation 


Schedule 

• Processing time 

• Contingency recycle time 

• Orbiter impact 

Management 

• Documentation 

• Organizational interfaces 



Figure 19. Quick-Reaction Integration Alternatives 


The conclusions drawn from this analysis are: 

• Cost and schedule differences between alternatives are of secondary 
importance when viewed from the user and programmatic perspectives. 
This results from the modularity of the Spacelab which allows con- 
venient air shipment of racks and modules. This conclusion is sub- 
stantially different from the first study in which a unitized Sortie 
Lab was used. 
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• Performance and management objectives are best met by accomplish- 
ing all integration at a single location. This is because the user 
works at only one location, and the problems of hardware turnover 
are minimized. 


4.0 IMPACT OF A SECOND LAUNCH SITE 

Because of the significantly different operational environment at the 
Western Test Range (WTR) , a separate analysis was performed to estimate the 
impact of the Quick-Reaction mode on WTR, The existing WTR operational plans 
were reviewed, QR operational flows were developed, and QR requirements were 
defined in the context of WTR capabilities. The effects on transportation, 
facilities, equipment, and manpower were estimated. 

The following assumptions were made with respect to the WTR operating 
environment in the Shuttle era: 

• The Air Force will be responsible for Shuttle operations, includ- 
ing Level I integration. 

e The resident NASA-WTR organization will operate in its traditional 
WTR host role, as it does currently for unmanned launches. 

• Non-DOD payloads will be processed by owner /operators using trans- 
ient crews. 

« The payload integration facility proposed for WTR will accommodate 
Spacelab processing. 

• A Spacelab Support Unit and its associated GSE will be permanently 
assigned to WTR to accommodate all Spacelab missions and will be 
shared by the QR missions . 

• A transient KSC Spacelab ground crew will perform Support Unit 
maintenance, mating, and final Spacelab checkout. 

In addition, it was assumed that all four levels of integration would be 
performed at WTR, maintaining all of the basic features of the QR concept. 

Within this framework, the principal issue is whether the Experiment Unit/ 
Pallets and supporting equipment should be permanently assigned to and located 
at WTR or permanently based at KSC. In the first case, the added cost of the 
flight hardware, support equipment, and storage space contributes to higher 
initial cost. In the second case, shipping the equipment to WTR for each 
flight contributes to higher operational cost, but it can also be used for 
flights from KSC. 
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Both options are technically and operationally feasible. The relative 
costs depend on WTR mission frequency. Both options should be kept open until 
this is determined. 

Since it is assumed that the proposed payload integration facility for 
WTR will accommodate Spacelab processing;, the impact on WTR facilities is 
minimal. Existing laboratory space, engineering offices, and shop facilities 
are adequate. Modifications to clean rooms and other specialized facilities 
may be required . 

Impact on support equipment also depends on mission frequency. Options 
are: ship existing equipment from KSC as needed; buy new equipment for WTR; 

share equipment with other WTR Spacelab programs. The most likely solution 
is some combination of these. 

With low flight density, a transient crew from KSC for each flight pro- 
vides the most efficient manpower utilization. This avoids much duplication, 
as most of the planning and paperwork can be done at KSC by the QR organiza- 
tion. About 33 transient personnel are required for each launch. If launch 
density increases, a combination of resident and transient crew would be more 
efficient . 

The principal conclusions derived from this analysis are that the QR con- 
cept can be implemented at WTR, and the frequency of QR missions will be the 
driver in selecting the best of several viable operating modes. 


5.0 MISSION FEASIBILITY 

Mission feasibility is concerned with the question of benefits versus 

cost . 

The most significant benefit of the Quick-Reaction concept is that it 
increases the potential Shuttle user market by providing a service which: 

• Provides rapid "concept-to-data-return" 

• Places minimum formal requirements on the users 

• Provides an economical means for certain low-budget users to partici- 
pate in the Space Program. 

This is accomplished by accommodating only simple-to- integrate experi- 
ments and providing a dedicated "Quick-Reaction” integration capability for 
this class of experiments. 
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The cost of implementing the concept, using the split-module Spacelab as 
experiment carrier and assuming two flights per year, is summarized as follows: 

Fixed Costs Recurrent Costs 


EU and Pallets 

$4 . 55M 

QR Organization 

$1.72M/Yr 

GSE 

1.30 

(62 people) 


Facilities 

0.7 




$6.55M 




These costs are based on 1973 dollars. Only dedicated resources are 
included. The Support Unit is not included as it is shared with other missions. 
Shuttle launch costs are not included. 

Using this data, and assuming about 9 to 11 experiments per flight, inte- 
gration costs are quite low - less than $100K per experiment. If Shuttle 
launch costs are included, the flight cost per experiment will be an order of 
magnitude higher. 

Thus , the baseline concept developed in this study provides a user- 
oriented, low- integration- cost service; however, the relatively high flight 
cost per experiment may discourage low-budget users. Another operational 
mode, the "space-available" concept, is more cost effective. 

6.0 THE SPACE- AVAILABLE CONCEPT 

Many Shuttle payloads will not use all of the Orbiter capabilities. This 
provides an opportunity to fly additional payloads on a "space-available" 
basis, sharing the launch costs with the primary payload. These additional 
payloads can be integrated on a Ouick-Reaction basis. 

"Space available" is defined as Orbiter capability remaining after all 
primary payload requirements are satisfied, and includes: 



Volume 

• 

Thermal control 


Weight 

• 

Data management 


On-orbit time 

• 

Communications 


Crew time 

• 

CG margin 


Electrical power 




Space may be available on a planned basis; that is, derived from the 
Traffic Model and firmed up as the primary payload is defined. It also may 
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be available on a contingency basis; that is* in a multiple-element payload, 
one element may slip in schedule, but the others must fly on schedule* Analysis 
of the October 1973 Traffic Model shows that 23 percent of the Shuttle flights 
could carry a planned space-available payload 10 feet in length and weighing 
up to 3000 pounds. Thus for a relatively small increment in flight cost, the 
potential exists, for providing large scientific returns* 

In the planned mode, the available space is earmarked relatively early 
in the development cycle, but the space-available payload is integrated in 
the QR mode. This provides the low-cost and schedule benefits to certain 
users , 

In the contingency mode, two options are available: 

Option A : A pre-integrated payload is built up, tested, and held on a 

standby basis. This provides very rapid availability of a substitute 
payload but, because the primary payload and mission parameters are not 
known during buildup, experiment selection is necessarily very restricted. 

Option B : A QR payload is built up for a specific mission. Although 

this option requires more time to respond to a primary payload failure, 
it also allows more efficient use of the available space and broader 
spectrum of experiments, 

A key difference between the space-available and the dedicated QR modes 
is that the experiment complement must now be selected to be compatible with 
primary payload mission parameters. Furthermore, the space-available payloads 
must have minimum interference with the primary payloads. 

An overview of the space-available concept is shown in Figure 20. Candi- 
date experiments are defined and logged in a data bank. When space availability 
is identified, experiments are selected which are compatible with primary 
mission parameters. These experiments are combined into appropriate space- 
available configurations. Selection of the specific flight configuration is 
based on optimum use of the available space and perhaps also other criteria 
such as scientific merit of the experiment complement. Once the flight configura- 
tion is selected, the integration process proceeds in much the same manner as 
the previously defined QR integration. 

In the planned mode, ample time normally is available to develop an experi- 
ment complement which makes optimum use of the available space. Several configu- 
rations may be developed and tested against appropriate selection criteria. In 
the contingency mode, failure of a primary payload element can occur as late as 
10 weeks prior to launch and a space-available payload can be integrated into it, 
but the opportunity to define an optimum payload is limited. 
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Figure 20, Space Available Concept Overview 

To test this concept, a specific case was analyzed in detail. The pri- 
mary mission selected was Astronomy Mission AST-1A, which delivers an Explorer 
to a 297-mile orbit, and retrieves two life sciences modules from a 300-mile 
orbit. This mission allows a space-available payload weight of 9700 pounds 
and provides over two days of experiment operations* The space-available 
configuration selected, shown in Figure 21, uses a Spacelab pallet section as 
a carrier and carries four earth-observation- type experiments* 

This analysis developed the integration and checkout requirements, ground 
operational flows, a mission profile, and resource requirements* The analysis 
results led to the following conclusions: 

• Space- available is the most cost-effective way to implement the 
QR concept. 

• Both the planned and the contingency modes should be retained as 
space-available options. 

• The standby mode is not suitable for QR space-available. 
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• Resource requirements are essentially similar to the dedicated QR 
mode. Manpower requirements will depend on flight density. 

• Quick-Reaction space-available payload development should not begin 
too early - a "domino 11 effect will occur due to primary payload 
changes, mission planning will be iterated unnecessarily, and the 
experimenter's involvement will be unnecessarily long. 


DESCRIPTION 



• WEIGHT: ^1400 POUNDS (640 KG) 

EXCLUDING EXPERIMENTS 

• width: FULL PAYLOAD BAY 

• length: ^10 FEET (3 meters) 

• STANDARD PAYLOAD SUPPORT 
SYSTEMS INTERFACE 

• ONBOARD THERMAL CONTROL, 

DATA LINK, AND ELECTRIC 
POWER DISTRIBUTION 
SUBSYSTEMS 

• WALK-ON CAPABILITY 


Figure 21. Spacelab Pallet Section for Space Available 


Further development of the space-available concept should consider flight 
modes other than the sortie mode; for example, the development of a OR free- 
flier may be feasible and cost effective. Other aspects to be considered 
include: the concerns of the primary payload owner; the liability aspects; 

and cost-sharing criteria. Finally, a more detailed investigation of automated 
mission planning techniques should be made to assure that the necessary flexi- 
bility can be provided. 
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